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New ;login: Editor 


This issue of ;login: is the first under a new production and 
editorial arrangement developed at the Delaware Usenix Association 
meeting in June of this year. Under this arrangement the University 
of Texas at Austin Computation Center will assume responsibility for 
the editorial and production requirements of the Newsletter. Wally 
Wedel of the Computation Center will undertake the editorial duties. 


At the Delaware meeting we had announced plans to issue a 
Newsletter as early as mid July. Those plans failed to materialize 
because of the difficulty of making the necessary arrangements during 
the summer in a large University environment. By the time you read 
this a proposed agreement between the University of Texas Computation 
Center and the Usenix Association should be in the mail to the Usenix 
Board of Directors. : 


We expect to be issuing ;login: on a monthly basis from now on. 
Newsletter deadlines 
Final copy for the newsletter will go to the printer on the first 
Wednesday of each month. The deadline for submittal of articles, 


announcements and letters will be the last Wednesday of the month. 


Guidelines for Submission of Newsletter Material 





I would Like to use the modern text preparation and communica— 
tions facilities of UNIX to as great an extent as feasible in the 
preparation of the Newsletter. I have established an account on our 
PWB/UNIX system so that those who can provide us with machine manage— 
able material can do so. The telephone number is (512) 474-5511. The 
login name is login and the password is usenix. (The system is also 
host utexas on the ARPANET.) 


For those submitting paper copy of material, please produce your 
eopy on a daisy wheel printer or similar high quality printing device, 
Line printer produced copy is typically not adequate for reproduction. 
Copy should be on 8 1/2" by 11" paper with a 1" margin on left, right, 
and bottom and 1 1/2" margin on top. 


U. S. Mail submissions should be addressed to: 
Login Newsletter 
Computation Center 
The University of Texas 
Austin, Tx 78712 


Attn: Wally Wedel 
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Meeting Announcement 


The next USENIX meeting is scheduled for San Francisco, Califor- 
nia, January 21-23, 1981. Tom Ferrin at the University of California, 
San Francisco will be hosting the meeting. Tom's mailing address is: 


Room 1022C, Medical Sciences Building 
UCSF 
San Franeiseo, CA 94143 


Details on accommodations, chairpersons, etc., will follow in the next 
newsletter. 


Beginning with the January meeting, it will be necessary for 
interested parties to submit abstracts of any proposed presentations. 
Hopefully, this will facilitate acceptable grouping of the talks. If 
you are planning to make a presentation at San Francisco, forward an 
abstract to Tom Ferrin. 


An~operr invitation-is issued to anyone interested in hosting 
future USENIX meetings. Meeting guidelines regarding frequency, for~ 
mat, content, ete., are currently being formulated by a committee. 
Any response about hosting a meeting or making suggestions for future 
meetings should be directed to: 


John L. Donnelly 

NCAR 

P.O. Box 3000 

Boulder, Colorado 80307 

(303) 494-5151 (ext. 527, 534) 
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Editorial 


The Newsletter 


The UNIX Newsletter ;login: is being revived! I have agreed to 
serve as editor until the Board of Directors chooses to pass these 
duties to someone else. As I stated at the Delaware Usenix meeting, 
my model for a newsletter such as this is the Pascal Newsletter. Andy 
Mickel of University of Minnesota, with the enthusiastic support of 
Pascal Users around the world made the Pascal Newsletter a vital force 
in bringing Pascal into widespread acceptance in the computing commun— 
ity. I hope we can do many of the same kinds of things for UNIX and C 
based programming systems. Much of the vitality of this Newsletter 
will depend on contributions of material from the UNIX user community. 
Types of material which are appropriate include: 


1) articles describing systems and programs developed using UNIX - or 
Cc. ; 


2) review of experience with UNIX or C based programming systems 
with ideas for improvements and reports of errors or mis— 
features. ; 


3) letters to the editor commenting on UNIX issues, USENIX issues, 
or broader general computing issues which may be of interest to 
UNIX or C users. 


4) description of new documents for UNIX and C related systems. 
5) new developments in software tools. 
6) USENIX business, 


Depending on the amount of material received for the Newsletter, I 
plan to organize the Newsletter into departments roughly along the 
lines of the items in the above list. Other departments will be 
created as required. 


Association Matters 


Many of us who have joined the Association are dubious about its 
future viability based largely on the problems which have been encoun- 
tered over the last couple of years in producing newsletters and dis- 
tribution tapes. Concern over these problems led me as a newly 
elected director to agree to develop a solution to the newsletter 
problem. I hope and expect to provide a satisfactory solution, Dis-— 
tribution tapes continue to be a problem. I for one am not yet satis— 
fied that progress is being made in this area. I hope to havea 
newsletter article this fall on the status of this program. 


To those of us who have experienced the frustrations of running a 
Usenix meeting it has appeared that the Association has provided far 
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too little support in the area of meeting planning and preparation. 
Board member John Donnelly is investigating this problem and hopefully 
will be able to provide some suggestions for effective assistance to 
meeting organizers. 


Two issues surfaced at the Delaware Meeting which clearly need 
further discussion and clarifying actions by the Board of Directors. 
The first issue is the question of whether employment recruiting 
should be permitted at Association meetings and if it is permitted 
what policies or rules might be established to control recruiting 
activities. As the situation now stands all recruiting is prohibited 
by action of the Board. The second issue is the question of vendor 
related activities at Usenix meetings and in this Newsletter. I 
encourage you to express your ideas on these matters in letters to the 
editor for future editions of ;login:. 
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Letter to the Editor 


Date: 21 Jul 1980 1001-PDT 

From: Mo at LBL-Unix (Mike O'Dell) 

Subject: Letter to the Editor (Usenix Newsletter) 
Os wedel at utexas 

ces mo, scherrer 


Wally, 


First, let me post the usual disclaimer that what I am 
about to say is my personal opinion and in no way reflects the views or 
- anything else of my current employer (Lawrence Berkeley Laboratory) or 
the Department of Energy. 


While on the whole, the Delaware Usenix meeting was a good conference 
(kudos to Ed Szurkowski), there were several incidents which raised my 
hackles then, and make me angry now. One was the issue of "reeruiting" 
and “employment notices." At the conference, President Lou Katz went around 
to the various bulletin boards placing a notice stating that employment 
interchanges of any kind were verboten at the meeting. A part of the 
notice was a planted letter by Ira Fuchs, director of the CUNY computing 
center. It is the attitude of Mr. Fuchs which I find offensive, and 
take great exception with President Katz for using his letter to support 
a decision which was clearly the decision of either the Usenix Board, or 
the President himself. An executive decision should stand on its own 
if it is to stand at all. But at any rate, since President Katz chose to 
use the letter as part of the notice, I feel it important to take issue 
with the viewpoint of the letter since it was somehow raised to legitemacy. 


In the letter, Mr. Fuchs presented the notion that he (and many other 
managers of "institutional members") would find it very difficult to send 
employees to meetings with the knowledge they would be exposed to employment 
activities. Mr. Fuchs claims they send to (sic) people to meetings to exchange 
information and not finance their job~hunting. But to constrict. the 
topics of conversation at a meeting is hardly within his rights. If Mr. 

Fuchs is really intent on insuring his personnel are not exposed to those 
nasty old job-offers, let's examine what it would take to do so. 


First, they could not be allowed to attend any conferences. While 
certain conferences do prohibit blatant recruiting efforts, one juicy 
topic at any meeting is who is doing what interesting things. I would 
suggest that in the Unix world, this is the basis of changing jobs 
(as opposed to SHARE, where almost nothing interesting is happening, 
anywhere, and money IS the big incentive). I speak from recent experience, 


Second, all their mail, both incoming and outgoing would have to 
be screened for "undesirable influences." Heaven knows what kind of 
heathens advertise positions in the back of Computerworld. Why, Ford 
Aerospace and Logicon and Computer Sciences Corporation are ALL looking 
for Unix personnel!!! 
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Third, they could not be allowed to read, let alone subscribe to 
newspapers. All kinds of people are advertising for technical people 
in newspapers, and New York (the address given on Mr. Fuchs's stationery) 
papers are probably one of the worst offenders. 


Finally, a serious manager must start thinking ahead. In Dallas, 
one can see Mostek billboards around the city. Just think what might 
be visible in Silicon Valley. Trips to and from work must be scrutinized 
for deleterious influences and alternate commuting routes proscribed. 
The ambitious manager could certainly think of other possible sources 
of contamination by foreign ideas. 


I claim that if this is the only way Mr. Fuchs can keep employees, 
he has a problem much larger than job notices posted on a bulletin 
board at a Usenix meeting. I would suggest that most of the Unix people 
I know would take great pleasure in telling an employer exactly (and 
graphically) what he could do with his job if it ever became know that 
was the reason the travel money dried=up at the last minute. I should 
like to believe that C is still a counter-culture language, and that the 
people that work around and believe in the Unix world view are basically 
different from the people that hack Cobol on DOS/VSE. .I will be the 
first to admit that nice salaries are important, but would suggest that 
the employer's effort to keep the employee happy, interested, and 
challenged are the real measure of whether the employer really desires 
the services of an employee. Besides, nothing is more worthless 
(or possibly more dangerous?) than a programmer doing a job he really 
does not like. 


All this is to advance the view that Mr. Fuchs position is basically 
untenable, and such a prohibition by Usenix is a pious, Pollyannish 
attitude. I can certainly agree with "modesty and decorum in all things," 
and think requests that such activities be low-key and unobtrusive are 
clearly in order. (Other kinds of efforts would probably be viewed in 
an "appropriate" light.) The harbor cruises and such which happen around 
NCC are probably excessive, and would probably be viewed rather humorously 
by most Unixers. But I don't think it proper to simply decee (sic) it "shall 
not happen here." 


While some of this may seem overstated, in light of conditions in 
other parts of the world, one should think very seriously about making 
statements and edicts to the effect of "Thou shalt not <x>." I wonder 
what excuse his boss used the first time when he told Sharansky he could 
not go to a meeting. 


Sincerely, and thoughtfully, 
Michael D. O'Dell 
(mo@1b1l-unix) 


US Mail address: 

CSAM — 50B/3234 

Lawrence Berkeley Laboratory 
University of California 
Berkeley, California 94720 
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Usenix Board Meeting Highlights 


The newly elected Usenix Officers assumed office at the Delaware 
Usenix meeting. The new Board members are: 


President Lou Katz, Columbia University 

Vice President Peter Wiener, Interactive Systems Corporation 

Board Member John Donnelly, National Center. for Atmospheric 
Research F 

Board Member Mel Ferentz, Rockefeller University ~ 

Board Member Lew Law, Harvard University 

Board Member Debbie Scherrer, Lawrence Berkeley Laboratory 

Board Member Wally Wedel, The University of Texas 


Mel Ferentz was re-elected Treasurer and Ira Fuchs of the City Univer— 
sity of New York was elected Secretary of the Association. 


New Usenix Membership Class 


Tne Board added a new membership class ealled a 
corporate/university-wide membership. Under this class of membership, 
a corporation.or university would have a single institutional vote but 
would be allowed to distribute tapes to other institutional sites. 
The membership fee will be the regular corporate or educational. rate 
plus 1/3 of the regular fee for each additional site or campus. 


Incorporation 


The Board is investigating the question of incorporating the 
Association. That question will be considered at a meeting of the 
Board scheduled for October in Boston. 


Committees 


Several committees were established by the Board to address prob- 
lems facing the Association. The Board itself will serve as a commit- 
tee to develop clear statements of purpose and to develop some _ posi- 
tion statements relative to other groups with overlapping interests 
such as the proposed DECUS UNIX SIG. A meeting committee was esta- 
blished with John Donnelly as the chair to find meeting sites, develop 
meeting guidelines, and oversee meeting arrangements. A newsletter 
committee was established with Wally Wedel as the chair to resolve the 
problems with regular appearance of the . newsletter. A distribution 
tape committee was established with John Fuchs as the chair to develop 
guidelines for the submission of material for distribution tapes and 
provide for collection of materials and development of distribution 
procedures. A by-laws committee was established with Ira Fuchs as the 
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chair to provide some much needed cleanup of the Association by~laws. 
Employment Activities at Association Meetings 


Tne Board discussed the unfortunate chain of events - surrounding 
the ban on recruiting which was announced at the Delaware meeting. 
The general sentiment was to conduct a poll of institutional members 
on this issue and to derive a position from poll results. 


Vendor Relations 


The Board discussed the problem of relations between the Associa-— 
tion and its vendors. The problem is to develop policies which 
encourage technical interchange between vendors and customers but 
avoid problems of too much sales PAtCH and heavy promotional activi- 
ties to a captive audience. 


Meetings 


The Board discussed having general Association meetings every 8 | 
to 9 months rather than every 6 months as is happening now. Yearly 
meetings are too far apart for new installations bringing up UNIX who 
want to-talk to experienced UNIX people. Six month meetings may be 
too frequent for the presentation of new and exciting work. The Board 
also suggested shortening meetings from 4 ae to 3 days with the pos— 
sibility of concurrent sessions. 


The board recommended that future meetings require abstracts of 
presentations from speakers before a slot on the agenda is assigned. 


Austin, Texas has been approved as a site for the June 1981 meet-— 
ing. The Board is trying to set up a meeting for January in the Bay 
Area. 
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A Proposal for an Othello Referee 


Geoff Coityer 


105-936 Bute St. 
Vancouver, BC, Canada 
V6E 1Y7 


ABSTRACT 


This memo is based upon my Othello program and experience at the June 
1979 and June 1980 USENIX conferences. 


The most flexible design for Othello (or any symmetric board game) seems to be (see 
Figure 1): ; 


e referee — a final authority, police-man, record-keeper, set-userid supervisor; 


e players — untrustworthy schemers, who may generate their own moves or consult the 
user to solicit moves; 


Ad display — responsible for showing the progress of the game, as reported by the referee. 


All piped communication is by standard ASCII protocols so that any process may be 
replaced. 


As parent, the referee can record CPU times of both players and termination statuses. 
Display really need not be a child. Referee might record times, final scores and all moves, and 
player-id’s. 

Rationale 
The proposed process structure accomodates: 


° tournament play: the referee runs two contenders, showing the results on the most con- 
venient device, and recording the result in a file (eg, /usr/othello/games), 


e testing: the referee runs two versions (repeatedly), recording results in a file, for evalua- 
tion (-s). 


e ordinary man-machine play: one player generates moves, the other accepts moves from 
the user, the referee keeps track (-m). 


e man-man play: both players accept moves from a tty. 


Advantages of this process structure 
This degree of decoupling allows: 
the referee’s output to be fee’d into a file for replay by the display process later; 
any suitable device to be driven by the display back-end; 
other uses of the back-ends (eg, by Chess, Life, Checkers). 


Each process is now-more robust. The back-ends are useful in their own right(s). Once 
the referee is proven correct or is deemed to be correct, cheating by any player is impossible 
since the referee will catch attempted cheating (appropriate action: this move is skipped, or 
automatic loss). 
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While the entire games evolves, new back-ends for colour TV’s can be written while ini- 
tial work is done on tty’s; smarter players can be written and tested mechanicaily against exist- 
ing players (humans or otherwise). 


For hand-to-hand combat, one can run a player standalone with a physical playing board. 
This interface is crude, with no checking of moves, and using the protocols directly. It is use- 
ful if the referee is ill. 


Implementation - 


A more realistic process structure is Figure 2. 


A word on integrity and interchangability: to guarantee symmetry of players, perhaps the 
rule-checking subroutine should be a separate process, which also lets us change the game by 
changing the rule-checker process. 


Players are files or pipes to processes. Oc is the Othello command; usage is 
oc [red] [black] 
Examples are: 


oc script] script 2 ;: debug referee 
oc human mijs | /usr/games/back/vsv01 ;: play mjs’s logic 


Retrospective 


The ‘human’ player, which accepts a user move in co-ordinates familiar to humans, may 
be viewed as.a front-end to either the referee or another player. For example, in hand-to-hand 
combat, one might say 


human | mjs 


in order to gain familiar co-ordinates when playing sans referee on a physical playing board. 


Oc is thus usefui for other games (eg, Chess): by using players and a referee of another 
game, one may share the back-ends and oc’s process initialization. An option might change the 
game (or maybe just the referee and defaults, since the players are named). 


Obviously, oc should default for missing arguments and the protocol between the referee 
and back-end should be intelligible so that 


oc 


will play reasonably: red is human; black is a reasonable player; moves are typed on the stan- 
dard output. 


cd /usr/games 
oc old new | tee slaughter | back/vsv 


might be used to debug a new player. 

oc - idiot.| back/vsv ;: - means human (or default) 
allows easy ego trips. 

oc - /dev/null 
also makes an easy (and short game). 

oc human human | vsv 


lets you whip someone in living colour. 
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Notes on Tournament Use 


The proposed Othello would have prevented the many problems encountered at the UNIX 
Othello tournament at the June 1979 and June 1980 conferences. 


A referee supplied by an impartial source could have run all players, recording results, 
showing games in progress, (from a script and) entirely without human interaction, thus complet- 
ing the tournament in minimum time and free of errors in typing, transcribing or converting 
from program A’s co-ordinates to program B’s co-ordinates. 


The tournament would thus have been pure enjoyment: since the same back-ends would 
likely have been used on all tty’s, a homogenous interface would have been presented: ta 
observers. Individual games could have been reviewed; indeed the entire tournament could 
have been played in half an hour, the winners announced, and interested parties could then 
have reviewed games of interest to them on available equipment. 


Suggested Back-ends 


Nil — hand-to-hand. Basic tty — showing the board. Direct cursor addressing for tty’s. 
Local colour TV interface. 
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Figure Z 


Legend: Circles represent processes. 
Lines with arrows represent pipes. 
Lines without arrows represent forks. 


